As is known, to securely transmit data from one party to another in a secure communication system, the transmitted data is encrypted using an encryption key and an encryption algorithm. Such an encryption algorithm may be a symmetric key algorithm such as the data encryption standard ("DES") and the encryption key corresponds with the symmetric key. Such a secure transmission begins when a sending party encrypts the data using the symmetric key algorithm and the symmetric key. Once the data is encrypted, it is transmitted to the receiving party over a transmission medium (i.e., Internet, telephone line, local area network, wide area network, etc.). Upon receipt, the receiving party decrypts the data using the same symmetric key, which must be transmitted to it or derived by it using a secure mechanism.
Encrypting data using a public key algorithm is somewhat more expensive than using a symmetric key algorithm but it is easier to convey the encryption key to the receiving party using the public key algorithm than using the symmetric key algorithm. Thus, to obtain the cost saving benefits of symmetric key encryption and the key distribution advantages of public/private key pairs, a wrapped session key is provided to the receiving party along with the data that is encrypted using the symmetric key. The wrapped key is a symmetric key that has been encrypted using the encryption public key (of a public/private key pair) of the receiving party. When the receiving party receives the encrypted message, it decrypts the wrapped session key using its private key to recapture the symmetric key. Having recaptured the symmetric key, it utilizes it to decrypt the message. Typically, symmetric keys are used for a relatively short duration (e.g., a communication, a set number of communications, an hour, a day, a few days), while encryption public keys are used for a longer duration (e.g., a week, a month, a year or more).
To further enhance security of encrypted data transmissions in a secure communications system, the sending party provides its signature with encrypted messages that it transmits. The signature of the sending party consists of a tag computed as a function of both the data being signed and the signature private key of the sender. The receiving party, using the corresponding signature verification public key of the sending party, can validate the signature. To ensure that the receiving party is using an authentic signature verification public key of the sending party, a signature public key certificate is employed. The signature public key certificate includes the public key of the sending party and the signature of a certification authority. The receiving party first verifies the signature of the certification authority using the trusted public key of the certification authority which signed the certificate.
The receiving party has acquired trust in this public key by some other means, for example by having been initialized to trust this key and storing this key locally in a trusted manner. Another method for acquiring trust in this public key is through the use of a certificate chain, as is well known in the art. In a certificate chain, the root, or anchor, of trust is a public key which the receiving party has obtained trust in a priori, for example at the time of initialization. Once the signature of the certification authority on the certificate of the sending party is verified, the receiving party can trust the signature public key of the sending party and use this key to verify the signature of the sending party on the message. Similarly, the encryption public key of an intended recipient, as discussed earlier, is typically obtained by the sending party from a public key certificate and its validity is analogously verified prior to its use, in this case for encryption.
While the above signature verification process suffices in many circumstances, an end-user determines the validity of another end-user's public key based on the trusted public key of a certification authority which it already possesses. In this manner, the user either trusts all of the end-users affiliated with the particular certification authority or none. As such, a user is not able to trust some, but not all, of the end-users affiliated with a different certification authority. In addition, in systems such as those described in copending application entitled METHOD AND APPARATUS FOR PUBLIC KEY MANAGEMENT, having an attorney docket number of ENT970710-2, and assigned to the same assignee as the present patent application, an end-user may only receive trusted public key certificates from its own certification authority or another designated certification authority. The end user, however, is not authorized to receive trusted public key certificates from other end-users.
In yet other prior art systems, such as PGP (Pretty Good Privacy) system and an Entrust/Client system, an end-user's software may be configured to trust the public key certificate of another individual end-user, but this is limited to acquiring trust in one end-user at a time, and trust cannot be conveniently acquired in lists of certificates corresponding to arbitrary subsets of end-users. In still other systems, such as in web browsers, the user's software includes a preconfigured list of trusted authority certificates. Such preconfiguring of lists limits security policy control, in that, a user may add or delete any certificates to the list that he or she desires. In addition, the preconfigured list only includes certificates of authorities.
To provide added flexibility and convenience in building communities of trust in secure communications systems, end-users need to be provided with the ability, when consistent with security policy, to obtain trust in the public keys of other users and other certification authorities through a combination of methods. In addition, end-users need to be provided the ability to obtain trust in the public keys of a subset of a certification authority's end-user community without necessarily having to trust the entire community. Furthermore, end-users need to be able to acquire such trust in subsets by a method more convenient than carrying out a separate configuration transaction for each end-user's key(s).